Aurora: recover pinned sources after codeload rate limits - #528

Summary

• Retry pinned Aurora source downloads on HTTP 429 and transient 5xx responses, honoring bounded Retry-After values.
• If codeload still returns a retryable error, fetch the exact pinned unified72 Git commit and verify both its commit and tree SHA-1 before archiving it.
• Keep permanent HTTP errors and codeload checksum mismatches fail-closed; record source acquisition method and archive digest in the preparation receipt.
• Add tests for retry bounds, fallback behavior, pin mismatches, cache integrity, and a local Git source fixture; update the MSeries handoff and roadmap.

This follows run 39836069576: unified72 received four codeload HTTP 429 responses after retrying, while the candidate profile passed source preparation, production checks, kernel build and package inspection. The updated commit is intended to verify the pinned Git fallback in a new isolated CI run. No source archive has been fetched locally, and no hardware, installed kernel, boot payload, or wip4 artifact has been produced.

Verification

• python3 -m unittest discover -s mseries/aurora -p 'test_*.py' — 83 tests passed.
• python3 -m py_compile mseries/aurora/candidate.py mseries/aurora/test_candidate.py — passed.
• bash mseries/validate.sh --only docs — 4 checks passed.
• git diff --check — passed.
• Prior-head validation run 39836069653 — all jobs passed; public kernel packaging run 39836069596 — passed.

The PR workflow uses isolated ARM64 runners. It builds and inspects candidate packages after source preparation; it does not install or boot them.